home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / protocol / standard / ccitt / 1992 / x / x403_1.asc < prev    next >
Text File  |  1993-07-14  |  43KB  |  1,270 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Recommendation X.403
  8.  
  9.              MESSAGE HANDLING SYSTEMS - CONFORMANCE TESTING
  10.          
  11.                 The CCITT,
  12.                 
  13.          considering
  14.                          
  15.                 (a)     the need for Message Handling Systems;
  16.                 
  17.                 (b)     the need to ensure the interoperability of Message
  18.                         Handling Systems;
  19.                 
  20.                 (c)     the need for conformance testing specifications for
  21.                         Message Handling Systems;
  22.                 
  23.                 (d)     that the X.400-Series Recommendations specify
  24.                         Message Handling Systems;
  25.                 
  26.                 (e)     the state-of-the-art of OSI testing methodology and
  27.                         notation within CCITT-ISO,
  28.                 
  29.                   unanimously declares
  30.                 
  31.                 (1)     that this Recommendation describes the testing
  32.                         methodology for Message Handling Systems;
  33.                 
  34.                 (2)     that this Recommendation describes a notation used
  35.                         to define test specifications for Message Handling
  36.                         Systems;
  37.                 
  38.                 (3)     that this Recommendation describes the scope and
  39.                         content of CCITT Conformance Testing Specification
  40.                         Manuals for Message Handling Systems.
  41.                 
  42.  
  43.                                CONTENTS
  44.          
  45.          0.  Introduction
  46.  
  47.          1.  Scope and Field of Application
  48.  
  49.          2.  References
  50.  
  51.          3.  Definitions
  52.  
  53.          4.  Abbreviations
  54.  
  55.          5.  Conventions
  56.  
  57.          6.  Overview
  58.  
  59.          7.  Conformance requirements
  60.  
  61.          8.  Testing methodology
  62.  
  63.          9.  Structure of test suites
  64.  
  65.          10. Information to be supplied by implementors
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.          11. Test Notation
  79.  
  80.          12. Conformance Assessment Procedures
  81.  
  82.          Annex A  Test Notation
  83.  
  84.          Annex B  IPMS(P2) PICS Proformas
  85.  
  86.          Annex C  MTS(P1) PICS Proformas
  87.  
  88.          Annex D  RTS PICS Proformas
  89.  
  90.  
  91.          
  92.          0.  Introduction
  93.          
  94.          This Recommendation describes the test methods, test criteria and
  95.          test notation to be used for the conformance testing of message
  96.          handling systems based on the 1984 X.400 series of Recommendations
  97.          as supplemented by the X.400-Series Implementor's Guide
  98.          (version 5).
  99.          
  100.          1.  Scope and Field of Application
  101.          
  102.          The message handling protocols in the scope of this Recommendation
  103.          are contained in the 1984 X.400-Series of Recommendations together
  104.          with the X.400 series Implementor's Guide (version 5).
  105.          
  106.          Abstract test specifications for these are contained in the CCITT
  107.          Conformance Testing Specification Manuals associated with this
  108.          Recommendation:
  109.          
  110.           -  Conformance Testing Specification Manual for IPMS(P2)
  111.           -  Conformance Testing Specification Manual for MTS(P1)
  112.           -  Conformance Testing Specification Manual for RTS
  113.          
  114.          Even though these Manuals are referred to by this Recommendation
  115.          they are not part of it.
  116.          
  117.          While the complete and correct operation of session, transport and
  118.          other lower-layer protocols is required for interworking the
  119.          testing of these layers is not in the scope of this Recommendation.
  120.          On the other hand, X.400 conformance tests should verify that the
  121.          Reliable Transfer Server (RTS) correctly uses the layers beneath
  122.          it.
  123.          
  124.          The tests defined in this document apply to inter-domain working
  125.          (ADMD to ADMD and ADMD to PRMD). They relate to any MTA or UA in a
  126.          domain that supports communications with other domains.
  127.          
  128.          Conformance testing of the semantics and syntax of the actual body
  129.          part information carried in a BODY PART is beyond the scope of this
  130.          document.
  131.          
  132.          The purpose of this Recommendation is to minimize the time and
  133.          expense that manufacturers of X.400 implementations and providers
  134.          of X.400 services must incur to ensure a high degree of
  135.          interoperability of their equipment. This purpose is achieved by
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.          having a set of X.400 conformance test specifications. The
  143.          successful joint execution of the test specifications by two
  144.          implementations can be accepted as compelling evidence of the
  145.          complete and correct operation of these implementations.
  146.  
  147.          The scope and intention of this Recommendation is different from
  148.          other CCITT Recommendations which define communication services and
  149.          protocols such as the 1984 X.400-Series of Recommendations. The
  150.          purpose of the latter Recommendations is to unambiguously define a
  151.          system. However a Recommendation for conformance testing provides
  152.          a well chosen subset of tests of the virtually infinite
  153.          number of tests needed to guarantee full compliance to a protocol
  154.          standard. The subset is chosen in such a way that it gives a high
  155.          level of confidence that tested implementations will interwork
  156.          while taking into account pragmatic considerations such as time
  157.          taken to perform the tests.
  158.          
  159.          Testing for conformance to functional standards is beyond the scope
  160.          of this Recommendation. However it is recognized that conformance
  161.          tests for functional standards can be derived from this
  162.          Recommendation and the associated Test Specification Manuals.
  163.          
  164.          It should be recognized that the conformance testing of message
  165.          handling systems may fall within the framework of national
  166.          regulations and may be subject to the testing policies of
  167.          Administrations which are beyond the scope of this document.
  168.          
  169.          2.  References
  170.          
  171.          X.400  Message Handling Systems: System Model-Service Elements,
  172.                 version 1984.
  173.          
  174.          X.401  Message Handling Systems: Basic service elements and
  175.                 optional user facilities, version 1984.
  176.          
  177.          X.408  Message Handling Systems: Encoded information type
  178.                 conversion rules, version 1984.
  179.          
  180.          X.409  Message Handling Systems: Presentation transfer syntax
  181.                 and notation, version 1984.
  182.          
  183.          X.410  Message Handling Systems: Remote operations and
  184.                 reliable transfer server, version 1984.
  185.          
  186.          X.411  Message Handling Systems: Message transfer layer,
  187.                 version 1984.
  188.          
  189.          X.420  Message Handling Systems: Interpersonal messaging
  190.                 user agent layer, version 1984.
  191.          
  192.          X.210  Open Systems Interconnection (OSI) Layer Service
  193.                 Definitions Convention, version 1984.
  194.          
  195.          X.400  Series (1984) Implementor's Guide version 5.
  196.          
  197.          3.  Definitions
  198.          
  199.          3.1  Service Convention Definitions
  200.          
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.          This Recommendation makes use of the following terms defined in
  213.          Recommendation X.210, version 1984:
  214.          
  215.          a)   primitive;
  216.          
  217.          b)   request (primitive);
  218.          
  219.          c)   indication (primitive);
  220.          
  221.          d)   response (primitive);
  222.          
  223.          e)   confirm (primitive).
  224.          
  225.          
  226.          3.2  Message Handling Definitions
  227.          
  228.          This Recommendation makes use of the following terms defined in
  229.          Recommendation X.400, version 1984:
  230.          
  231.          a)   administration management domain;
  232.          
  233.          b)   interpersonal message [X.420];
  234.          
  235.          c)   message;
  236.          
  237.          d)   message transfer [X.411];
  238.          
  239.          e)   originator;
  240.          
  241.          f)   private management domain;
  242.          
  243.          g)   recipient;
  244.          
  245.          h)   user.
  246.          
  247.          4.  Abbreviations
  248.          
  249.          The following abbreviations are used in this Recommendation:
  250.          
  251.          ADMD   Administration management domain;
  252.          
  253.          ASP    Abstract Service Primitive;
  254.          
  255.          DSE    Distributed Single layer Embedded testmethod;
  256.          
  257.          MHS    Message Handling System;
  258.          
  259.          IPMS   Interpersonal Messaging System;
  260.          
  261.          IUT    Implementation Under Test;
  262.          
  263.          MPDU   Message Protocol Data Unit;
  264.          
  265.          MT     Message Transfer;
  266.          
  267.          MTA    Message Transfer Agent;
  268.          
  269.          MTS    Message Transfer System;
  270.          
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.          P1     The Message Transfer Protocol [X.411];
  278.          
  279.          P2     The Interpersonal Messaging Protocol [X.420];
  280.          
  281.          PCO    Point of Control and Observation;
  282.          
  283.          PICS   Protocol Implementation Conformance Statement;
  284.          
  285.          PIXIT  Protocol Implementation Extra Information for Testing;
  286.          
  287.          PDU    Protocol data unit;
  288.          
  289.          PRMD   Private management domain;
  290.          
  291.          RTS    Reliable Transfer Server;
  292.          
  293.          SAP    Service Access Point;
  294.          
  295.          TSP    Test Suite Parameter;
  296.          
  297.          TTCN   Tree and Tabular Combined Notation;
  298.          
  299.          UA     User Agent.
  300.          
  301.          5.  Conventions
  302.          
  303.          No conventions are defined for this Recommendation.
  304.  
  305.          6.  Overview
  306.           
  307.          There are two kinds of CCITT documents concerned with
  308.          X.400 Conformance testing:
  309.          
  310.          (a) This CCITT Recommendation entitled "X.403 Message  Handling
  311.              Systems: Conformance Testing".
  312.          
  313.          (b) Three associated CCITT Conformance Testing Specification
  314.              Manuals entitled:
  315.          
  316.           -  Conformance Testing Specification Manual for IPMS(P2)
  317.           -  Conformance Testing Specification Manual for MTS(P1)
  318.           -  Conformance Testing Specification Manual for RTS
  319.          
  320.          The CCITT Recommendation is intended for a wide readership. The
  321.          Manuals are intended for test implementors and contain detailed
  322.          test specifications.
  323.          
  324.          
  325.          6.1  The X.400 Conformance Testing Recommendation
  326.          
  327.          This Recommendation gives the following information:
  328.          
  329.          (a) Conformance requirements of X.400 implementations.
  330.          
  331.          (b) The testing methodology.
  332.          
  333.          (c) The structure of the test specifications.
  334.          
  335.          (d) Information to be supplied by implementors as a prerequisite to
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.              conformance testing.
  348.          
  349.          (e) The test notation.
  350.          
  351.          (f) Conformance assessment procedures.
  352.          
  353.          6.2  The X.400 Conformance Testing Specification Manuals
  354.          
  355.          Three CCITT Conformance Testing Specification Manuals contain test
  356.          specifications for the IPMS(P2), MTS(P1), RTS. The test
  357.          specifications are written in a notation described in general terms
  358.          in clause 11. The Conformance Testing Specification Manuals are
  359.          referred to by this Recommendation but they are not part of it.
  360.          
  361.          Since the Manuals contain detailed and unambiguous test
  362.          specifications, users of these Manuals should be familiar with the
  363.          X.400-Series of Recommendations and with the testing methodology
  364.          used.
  365.  
  366.          7.  Conformance requirements
  367.          
  368.          The purpose of the test specifications referenced by this
  369.          Recommendation is to define tests that will establish to a high
  370.          degree of confidence that the various protocol layers of an
  371.          implementation under test conform to the requirements of the X.400
  372.          series of Recommendations (1984).
  373.          
  374.          A system claiming to conform to the X.400 IPM-Service has to
  375.          support correctly:
  376.          
  377.           -  the basic IPM service elements as defined in X.400/Table 2
  378.          
  379.           -  the IPM Optional User facilities defined as Essential in
  380.              X.401/Table 1 and Table 2 (where the categorization for
  381.              origination and reception should be considered)
  382.          
  383.           -  the IPM Optional User facilities defined as Additional in
  384.              X.401/Table 1 and Table 2, which are claimed to be supported
  385.          
  386.           -  the requirements related to the IPM service as defined
  387.              in version 5 of the CCITT X.400-Series Implementor's Guide.
  388.          
  389.          A system claiming to conform to the X.400 MT-service has to
  390.          support correctly:
  391.          
  392.           -  the basic MT-service elements as defined in X.400/Table 1
  393.              related to the MTS(P1) protocol
  394.          
  395.           -  the MT Optional User facilities defined as Essential in
  396.              X.401/Table 3 and 4 and related to the MTS(P1) protocol
  397.          
  398.           -  the MT Optional User facilities defined as Additional in
  399.              X.401/Table 3 and 4 and related to the MTS(P1) protocol,
  400.              which are claimed to be supported
  401.          
  402.           -  the requirements related to the P1 MT-service as defined
  403.              in version 5 of the CCITT X.400-Series Implementor's Guide.
  404.          
  405.          A system claiming to conform to the X.400 RTS-service has to
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.          support correctly:
  413.          
  414.           -  the RTS-services as defined in X.410
  415.          
  416.           -  the requirements related to the RTS-Service as defined in
  417.              version 5 of the CCITT X.400-Series Implementor's Guide.
  418.          
  419.          Claims of conformance of an implementation to the X.400-Series of
  420.          Recommendations   can   be   tested    using    the    Conformance    Testing
  421.     Specification Manuals associated with this Recommendation to
  422.          ensure that:
  423.          
  424.          (a) The implementation does not act or react in a way different to
  425.              the one described in the Recommendations.
  426.          
  427.          (b) The implementation is capable of handling protocol errors.
  428.          
  429.              The reaction of an implementation on receipt of protocol errors
  430.              is not defined in the X.400 Series of Recommendations. For the
  431.              purpose of conformance testing the minimum additional
  432.              requirement is made that the implementation subsequently
  433.              continues to operate normally in such cases.
  434.             
  435.              The absence of a mandatory protocol element in P2 or P1 is
  436.              regarded as a protocol error. It should be noted that in an
  437.              implemented MHS a recipient domain may choose to deliver an
  438.              incorrect MPDU.  This should be considered as proprietary design
  439.              by the equipment vendor, and the specific actions taken in these
  440.              situations are defined by the vendor and not subject to
  441.              conformance.
  442.          
  443.          (c) The implementation correctly handles the requirements defined
  444.              in X.400 Implementor's Guide Version 5.
  445.          
  446.              Maximum lengths and maximum number of occurrences are
  447.              interpreted in the following way:
  448.          
  449.              - on origination: the implementation may support maximum
  450.                lengths/occurrences up to but not exceeding the constraint
  451.                value.
  452.             
  453.              - on reception: the implementation must support the maximum
  454.                lengths/occurrences of the constraints. Values above the
  455.                constraints may be supported but the conformance requirements
  456.                on the implementation upon reception of a length/occurrence
  457.                exceeding the constraint are the same as for protocol errors.
  458.          
  459.          Claims of conformance to the X.400 series of Recommendations can
  460.          not be tested for those implementations for which it is not
  461.          possible to perform all the required tests for features labeled
  462.          mandatory, basic or essential optional.
  463.  
  464.  
  465.          8.  Testing methodology
  466.          
  467.          8.1  Test configurations
  468.          
  469.          Two test configurations are used. The first configuration is shown
  470.          in Figure 1/X.403 and is used to test IPMS(P2), MTS(P1) and RTS.
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.          
  483.          
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.          Figure 1/X.403  End system configuration.
  494.          
  495.          
  496.          The second configuration is shown in Figure 2/X.403 and is used to
  497.          test the relay aspects of the MTS(P1) protocol.
  498.          
  499.          
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.          
  510.          Figure 2/X.403  Relaying MTA test configuration.
  511.          
  512.          
  513.          8.2  Points of Control and Observation
  514.          
  515.          Test cases are described abstractly in terms of events at points of
  516.          control and observation (PCO) in both the tester and the
  517.          implementation under test (IUT). These PCOs are generally Service
  518.          Access Points (SAPs) and the events are generally Abstract Service
  519.          Primitives (ASPs). This does not imply that manufacturers are
  520.          required to have accessible SAPs or to implement ASPs within their
  521.          systems. During test execution the PCOs of an IUT may be accessed
  522.          indirectly through a user interface. Where testing is performed
  523.          through a user interface, the mapping of events between the SAP and
  524.          the user interface is provided by the supplier of the IUT as
  525.          described in clause 10.2.
  526.          
  527.          8.2.1  PCOs for IPMS(P2)
  528.          
  529.          The IPMS(P2) test cases are described using the Points of Control
  530.          and Observation (PCOs) shown in Figure 3/X.403:
  531.          
  532.                                                   
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.          
  551.          Figure 3/X.403  Points of control and observation for IPMS(P2).
  552.          
  553.          
  554.          For the tester, the Point of Control and Observation is the Service
  555.          Access Point (SAP) defined at the boundary between the User Agent
  556.          Layer and the Message Transfer Layer. This PCO makes use of the
  557.          Message Transfer Layer Service Primitives defined in
  558.          Recommendation X.411.
  559.          
  560.          For the IUT, the PCO is the SAP defined at the upper boundary of
  561.          the User Agent Layer. However Recommendation X.420 does not include
  562.          definition of Service Primitives and it has therefore been
  563.          necessary to construct hypothetical ones for sending and receiving
  564.          IP-messages, in order that the test cases can be described in a
  565.          formal way.
  566.          
  567.          
  568.          8.2.2  PCOs for MTS(P1)
  569.          
  570.          The MTS(P1) test cases are described using the PCOs shown in
  571.          Figure 4/X.403:
  572.          
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.          
  589.          
  590.          Figure 4/X.403  Points of control and observation for MTS(P1).
  591.  
  592.          
  593.          For the tester, the PCO is the SAP defined at the boundary between
  594.          the MT Layer and the RTS. This PCO makes use of the RTS primitives
  595.          defined in Recommendation X.410.
  596.          
  597.          For the IUT, the PCO is the SAP defined at the boundary between the
  598.          UA Layer and the MT Layer. This PCO makes use of the MT Service
  599.          Primitives defined in Recommendation X.411.
  600.          
  601.          The testing of relay functions requires more than one tester SAP.
  602.          Similarly the testing of multiple destination delivery requires
  603.          more than one UA on the IUT.
  604.          
  605.          8.2.3  PCOs for RTS
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.          
  618.          The RTS test cases are described using the PCOs shown in
  619.          Figure 5/X.403:
  620.          
  621.                                                   
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.                                                    
  639.          
  640.          Figure 5/X.403  Points of control and observation for RTS.
  641.          
  642.          
  643.          For the tester, the PCO is the SAP defined at the boundary between
  644.          the RTS and the Session Layer. This PCO makes use of the Session
  645.          Service Primitives defined in Recommendation X.215.
  646.          
  647.          For the IUT, the PCO is the SAP defined at the upper boundary of
  648.          the User Agent Layer. This PCO makes use of the same hypothetical
  649.          Service Primitives defined for IPMS(P2) (section 8.2.1).
  650.          
  651.          The description of the RTS test cases includes events at a third
  652.          SAP at the IUT (SAP-I) between the MT Layer and RTS. The events of
  653.          this SAP are used only for clarification and it is not used as a
  654.          PCO.
  655.          
  656.  
  657.  
  658.  
  659.          8.3  Test Design Strategy
  660.          
  661.          The MHS test specifications are designed using the following
  662.          concepts:
  663.          
  664.          (a) A test specification is defined as a test suite composed of a
  665.              number of test cases as defined in clause 11.1.
  666.          
  667.          (b) Test cases are defined in terms of
  668.          
  669.              - lower layer ASP events at the tester
  670.              - upper layer ASP events at the IUT
  671.          
  672.          (c) The test cases define the sequencing of these ASP events and
  673.              the associated parameters, in particular the PDUs.
  674.          
  675.          (d) Test cases for valid behaviour specify ASP event sequences and
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.              PDUs that are in accordance with the X.400 series of
  683.              Recommendations.
  684.          
  685.          (e) Test cases for invalid behaviour are characterized by:
  686.          
  687.              - A correct PDU or event initiated by the tester in a protocol
  688.                state where it is not permitted (an inopportune event), or
  689.             
  690.              - a correct PDU incorporating an element which is
  691.                syntactically correct and in range, but conflicts with the
  692.                negotiated value, or
  693.             
  694.              - a PDU sent by the tester which is syntactically incorrect
  695.                (examples are a missing mandatory protocol element, an out-of-
  696.                range value or an incorrectly encoded length indicator) or
  697.             
  698.              - for RTS a lower layer ASP event issued by the tester used with
  699.                parameters that are not allowed or not appropriate (example
  700.                SPSN in SConnect) by X.400 restrictions.
  701.          
  702.          (f) The depth of testing is restricted to a reasonable
  703.              number of test cases using the following principles:
  704.          
  705.              For valid behaviour:
  706.             
  707.              - If there is a small number of valid protocol element values,
  708.                test all of them.
  709.             
  710.              - If there is a range of values, test the bounds and a few
  711.                common values.
  712.             
  713.              - If there are no bounds, test an extreme value besides the
  714.                common ones.
  715.             
  716.              For invalid behaviour:
  717.             
  718.              - The number of test cases for a particular type of error is
  719.                reduced to one or just a few common ones.
  720.          
  721.          8.3.1  Strategy for X.409 testing
  722.          
  723.          The X.409 test cases defined in the CCITT Conformance Testing
  724.          Specification Manuals associated with this Recommendation are
  725.          applicable only to X.400 message handling systems. The testing of
  726.          X.409 is done as part of the MTS(P1), IPMS(P2) and RTS testing. The
  727.          features tested are the data types defined in X.409, the various
  728.          forms of length encoding and the use of primitive and constructor
  729.          data elements. To increase the likelihood that the tests can be
  730.          performed, the test cases wherever possible have been defined using
  731.          the protocol elements associated with mandatory service elements.
  732.          
  733.          Two categories of X.409 tests are identified:
  734.          
  735.           -  Decoding Tests
  736.          
  737.              These tests are constructed by identifying X.409 features to be
  738.              exercised and devising sets of correctly and incorrectly encoded
  739.              test PDUs containing these features. The tests are performed by
  740.              transmitting the test PDUs to the IUT and observing the local
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.              reaction of the implementation and/or any PDUs returned to the
  753.              tester.
  754.             
  755.           -  Encoding Tests
  756.             
  757.              These tests are constructed by identifying a set of user service
  758.              requests that will generate PDUs whose encoding will exercise
  759.              major X.409 features. The tester must check the validity of the
  760.              coding of the resulting PDUs generated by the IUT.
  761.          
  762.          The decoding tests allow the X.409 decoding features of an
  763.          implementation to be fully exercised using valid and invalid test
  764.          PDUs. Encoding tests only allow the valid behaviour of X.409
  765.          encoding to be checked.
  766.          
  767.          8.3.2  Strategy for IPMS(P2) testing
  768.          
  769.          Two categories of test are identified :
  770.          
  771.           -  IUT as originator
  772.           -  IUT as recipient
  773.          
  774.          With the IUT as originator, for each service element supported by
  775.          the implementation, tests are performed by:
  776.          
  777.           -  Invoking the service.
  778.           -  The tester checking the validity of the resulting PDUs.
  779.           -  Where appropriate the tester returning valid and invalid
  780.              response PDUs to the originator.
  781.          
  782.          With the IUT as recipient, for each service element, tests are
  783.          performed by:
  784.          
  785.           -  The tester sending valid and invalid PDUs for that service.
  786.           -  Observing the local reaction of the UA.
  787.           -  Checking the validity of any further PDUs generated by the UA.
  788.          
  789.          In order to avoid unnecessary duplication of test cases, IPM
  790.          service elements which are also MT service elements (for instance
  791.          Delivery Notification) are listed in the MTS(P1) test suite in
  792.          conjunction with the corresponding MT service elements, and not in
  793.          the IPMS(P2) test suite.
  794.          
  795.          It is assumed that the testing of the MT layer is done through a
  796.          User Agent.
  797.          
  798.          8.3.3  Strategy for MTS(P1) testing
  799.          
  800.          When testing the operation of a MTS(P1) implementation five
  801.          categories of tests are identified.
  802.          
  803.           -  IUT as originator
  804.           -  IUT as recipient
  805.           -  IUT as relay
  806.           -  IUT as relay recipient
  807.           -  IUT as recipient/originator
  808.          
  809.          With the IUT as originator, for each service element supported by
  810.          the implementation, tests are performed by:
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.          
  818.           -  Invoking the service.
  819.           -  Checking the validity of the resulting PDUs.
  820.          
  821.          With the IUT as recipient, for each service element supported by
  822.          the implementation, tests are performed by:
  823.          
  824.           -  The tester sending valid and invalid PDUs for that service.
  825.           -  Observing the local reaction of the UA.
  826.           -  Checking the validity of any further PDUs generated by the UA.
  827.          
  828.          With the IUT as relay, for each service element tests are
  829.          performed by:
  830.          
  831.           -  The tester sending valid and invalid PDUs for relaying.
  832.           -  Checking the validity of the reaction of the IUT.
  833.          
  834.          With the IUT as a relay recipient, for each service element tests
  835.          are performed by:
  836.          
  837.           -  Sending a set of valid and invalid PDUs destined for more than
  838.              one recipient. At least one of these recipients is attached to
  839.              the IUT and a further recipient is attached to a remote MTA such
  840.              that the IUT has to relay the message.
  841.          
  842.           -  Checking the validity of the reaction of the IUT as recipient.
  843.          
  844.           -  Checking that the PDUs that are relayed are not corrupted and
  845.              are modified appropriately.
  846.          
  847.          With the IUT as a recipient/originator, for each service element
  848.          supported by the implementation, tests are performed by:
  849.          
  850.           -  Invoking the IUT to send a message to multiple recipients.
  851.              At least one recipient will be attached to the IUT itself and a
  852.              further recipient will be attached to a remote MTA.
  853.          
  854.           -  Checking the validity of the reaction of the IUT as recipient.
  855.          
  856.           -  Checking the validity of the PDUs transmitted by the IUT.
  857.          
  858.          8.3.4  Strategy for RTS testing
  859.          
  860.          The following testing phases are used:
  861.          
  862.          (a) The connection/association establishment and negotiation phase.
  863.             
  864.              The X.410 Recommendation allows different negotiable options and
  865.              the negotiation phase is tested exhaustively using valid and
  866.              invalid elements.
  867.          
  868.          (b) The orderly release of the connection/association.
  869.             
  870.              Only a few tests are required to check the correct
  871.              implementation of the RTS release features.
  872.  
  873.          (c) The data transfer phase with token exchange.
  874.             
  875.              The data transfer tests check:
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.          
  888.              - The correct operation of data transfer using the negotiated
  889.               values.
  890.             
  891.              - The correct operation of token exchange.
  892.             
  893.              - The correct confirmation of confirmed services.
  894.             
  895.              - The correct reaction to invalid (eg non-negotiated) elements.
  896.          
  897.          (d) Recovery
  898.             
  899.             Tests are performed to check that an IUT can perform correct
  900.             recovery after:
  901.             
  902.             - User aborts
  903.             
  904.             - Provider aborts
  905.             
  906.             - Exception reports
  907.             
  908.             - Not acknowledged checkpoints
  909.          
  910.          9.  Structure of test suites
  911.          
  912.          The IPMS(P2) and MTS(P1) test suites have a common structure which
  913.          differs from that of the RTS test suites.
  914.          
  915.          9.1  Structure of IPMS(P2) and MTS(P1) test suites
  916.          
  917.          The IPMS(P2) and MTS(P1) test suites consist of five groups of test
  918.          cases:
  919.          
  920.          (a) Initial Tests
  921.             
  922.              The Initial Tests check mandatory features in a small number of
  923.              test cases. They have been defined in order to check that the
  924.              implementation correctly supports the main mandatory features
  925.              and that it is sensible to continue with full conformance
  926.              testing.
  927.          
  928.          (b) X.409 Tests
  929.             
  930.              The X.409 Tests check the IUT's encoding and decoding of
  931.              protocol elements. Decoding tests are performed by transmitting
  932.              test PDUs to the IUT. Encoding tests are performed by checking
  933.              PDUs received from the IUT.
  934.          
  935.          (c) Protocol Element tests
  936.             
  937.              Protocol Element tests identify test purposes for every protocol
  938.              element in the IPMS(P2)/MTS(P1) protocols. This is important in
  939.              ensuring a full test coverage for the IPMS(P2)/MTS(P1)
  940.              protocols. Many of these tests are necessarily performed as part
  941.              of the Service Element tests.
  942.          
  943.          (d) Service Element tests
  944.             
  945.              Service Element tests check the capability of the IUT to support
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.              the service elements in X.400. Some of these tests are carried
  953.              out in the initial tests and the X.409 tests. Service Element
  954.              tests include both tests for specific service elements and tests
  955.              for combinations of interdependent service elements.
  956.          
  957.          (e) Additional Test
  958.             
  959.              The Additional Test group checks features not covered in the
  960.              other test groups.
  961.  
  962.          As indicated in (a) to (e) above the number of test cases has been
  963.          minimized by taking advantage of the fact that the performance of a
  964.          given test case may cover more than one test purpose. Figure
  965.          6/X.403 shows how some of the test purposes identified in a
  966.          particular test group may actually be achieved by test cases in
  967.          another group.
  968.          
  969.                                       
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.          
  980.          Figure 6/X.403  Structure of IPMS(P2) and MTS(P1) test suites.
  981.          
  982.  
  983.          9.2  Structure of RTS test suites
  984.          
  985.          The RTS test suite is made up of five groups of test cases:
  986.          
  987.           -  Association Establishment Tests
  988.           -  Association Release Tests
  989.           -  Data Transfer Tests
  990.           -  Association Recovery Tests
  991.           -  X.409 Tests
  992.          
  993.          The Association Establishment Tests check the negotiation of the
  994.          connection elements.
  995.          
  996.          The Association Release Tests check the orderly release of
  997.          associations.
  998.          
  999.          The Data Transfer Tests check that data is transferred correctly in
  1000.          accordance with the values of the connection elements negotiated
  1001.          during association establishment.
  1002.          
  1003.          The Association Recovery Tests check that the IUT can recover from
  1004.          breaks in connection both inside and outside activities.
  1005.          
  1006.          The X.409 Tests check the IUT's encoding and decoding of Session
  1007.          Service User Data.
  1008.          
  1009.          10.  Information to be supplied by implementors
  1010.          
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.          10.1  Protocol Implementation Conformance Statement (PICS)
  1023.          
  1024.          The Protocol Implementation Conformance Statement (PICS) is
  1025.          information supplied by an implementor that specifies the protocol
  1026.          features implemented in a Message Handling System.
  1027.          
  1028.          This information is used during conformance testing:
  1029.          
  1030.           -  To check that the protocol features that have been implemented
  1031.              are consistent with the conformance requirements, in terms of
  1032.              optional and mandatory features, of the X.400 series
  1033.              Recommendations.
  1034.          
  1035.           -  To select the originator tests to be executed. Recipient and
  1036.              relay tests will be performed to check the behaviour of the
  1037.              system even when it is requested to handle features that it does
  1038.              not implement.
  1039.          
  1040.          PICS proformas for IPMS(P2), MTS(P1) and RTS are shown in Annex B,
  1041.          C and D. These proformas specify the information to be supplied by
  1042.          an implementor concerning:
  1043.          
  1044.           -  The services that are supported for origination, reception and
  1045.              relay functions.
  1046.          
  1047.           -  The protocol features that have been implemented in order to
  1048.              support the services.
  1049.          
  1050.        The  IPMS  (P2)  PICS  explicitly  includes  the  MTS  (P1)  service  elements
  1051.        made    available    by    the    IPMS    (P2).    In    order    to     avoid
  1052.        duplication  with  the  MTS  (P1)  test  suite,  tests  for  such   MTS   (P1)
  1053.        service   elements   are   not   contained   in    the    IPMS    (P2)    test
  1054.        suite.  Where  the  testing  of  MTS   (P1)   is   not   performed   using   a
  1055.        UA,  MTS  (P1)   tests   may   need   to   be   repeated   using   a   UA   in
  1056.        order to ensure conformance to the IPMS (P2).
  1057.          
  1058.          10.2  Protocol Implementation Extra Information for Testing (PIXIT)
  1059.          
  1060.          The Protocol Implementation eXtra Information for Testing (PIXIT)
  1061.          is supplied by an implementor specifying information needed by a
  1062.          tester to execute a test suite.
  1063.          
  1064.          The IPMS(P2), MTS(P1) and RTS test suites define the behaviour of
  1065.          the implementation in terms of abstract service primitives. In
  1066.          order to invoke and observe this behaviour during test execution
  1067.          the test operator must know how (if at all) these abstract service
  1068.          primitives can be invoked or observed at the real accessible user
  1069.          interface.
  1070.          
  1071.          The IPMS(P2), MTS(P1) and RTS PIXIT proformas will list all the IUT
  1072.          upper layer abstract service primitives used in the test
  1073.          definitions and will ask the implementor to specify how these
  1074.          primitives can be invoked or observed (if at all).
  1075.          
  1076.          11.  Test Notation
  1077.          
  1078.          11.1  Definitions
  1079.          
  1080.          The notation used to define the MHS test specifications makes use
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.          of the following definitions:
  1088.          
  1089.          (a) Test Suite
  1090.             
  1091.              A set of test cases, possibly combined into nested test groups,
  1092.              necessary to perform conformance testing of an implementation.
  1093.             
  1094.              The test suites do not imply an order of execution.
  1095.          
  1096.          (b) Test Group
  1097.             
  1098.              A set of related test cases. Test groups may be nested to
  1099.              provide a logical structuring of test cases.
  1100.          
  1101.          (c) Test Case
  1102.             
  1103.              Specifies the sequences of test events required to achieve the
  1104.              purpose of the test and to assign a verdict "pass", "fail" or
  1105.              "inconclusive".
  1106.          
  1107.          (d) Test Event
  1108.             
  1109.              An indivisible unit of test specification at the level of
  1110.              abstraction of the specification (e.g. sending or receiving a
  1111.              single PDU).
  1112.          
  1113.          (e) User
  1114.             
  1115.              A user-interface process or a computer application which makes
  1116.              use of an MHS.
  1117.  
  1118.          11.2  Notation
  1119.          
  1120.          The Conformance Test Suites for Message Handling Systems use the
  1121.          Tree and Tabular Combined Notation as described in Annexe A of this
  1122.          Recommendation.
  1123.          
  1124.          Each test suite specification is defined in six sections:
  1125.          
  1126.           1  Introduction
  1127.          
  1128.              This contains an overview describing the scope of the tests and
  1129.              the structure of the test suite.
  1130.          
  1131.           2  Summary of Test cases
  1132.          
  1133.              This is a list of all tests giving the test identifier, the
  1134.              test reference and a short title for each test case in the test
  1135.              suite.
  1136.          
  1137.           3  Declarations Part
  1138.          
  1139.              Declares the names and types of all items to be used in
  1140.              defining the test cases.
  1141.          
  1142.           4  Dynamic Part
  1143.          
  1144.              This is the main body of the test suite and defines test cases
  1145.              in terms of trees of behaviour.
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.          
  1158.           5  Constraints Part
  1159.          
  1160.              Specifies the values of the ASPs and PDUs used in the Dynamic
  1161.              Part.
  1162.          
  1163.           6  Cross references
  1164.              
  1165.              Provides an index to all values used in the main body of the
  1166.              test suite.
  1167.          
  1168.          12.  Conformance Assessment Procedures
  1169.          
  1170.          This Recommendation deals only with abstract test specifications
  1171.          for Message Handling Systems. It does not deal with the realization
  1172.          of these test specifications nor with their execution. This clause
  1173.          in the Recommendation is purely for information purposes to
  1174.          describe in general terms how real testing may be done.
  1175.          
  1176.          12.1  Overview of the Procedure
  1177.          
  1178.          The procedures needed to assess the conformance of an
  1179.          implementation include:
  1180.          
  1181.           -  The completion of the PICS and PIXIT proformas by the supplier
  1182.              of the implementation.
  1183.          
  1184.           -  The assessment of these documents.
  1185.          
  1186.           -  The selection and execution of test cases.
  1187.          
  1188.           -  The analysis of the results and the production of test reports.
  1189.          
  1190.          
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.          
  1223.          Figure 7/X.403 The Conformance Assessment Procedure.
  1224.          
  1225.  
  1226.          12.2  Analysis of PICS
  1227.          
  1228.          The first phase in conformance assessment is to ensure that the
  1229.          features claimed to be supported by an IUT comply with appropriate
  1230.          conformance requirements. The conformance requirements for
  1231.          IPMS(P2), MTS(P1) and RTS implementations are defined in clause 7
  1232.          of this document. This check is performed by analysing the
  1233.          information in the PICS documents.
  1234.          
  1235.          12.3  Test Case Selection
  1236.          
  1237.          The tests to be performed are selected primarily on the basis of
  1238.          information in the PICS. For every supported feature claimed in the
  1239.          PICS the corresponding test cases in the test suites are selected
  1240.          and executed to check the correct implementation of these features
  1241.          under an extensive range of valid and invalid conditions.
  1242.          
  1243.          For non-supported features, some recipient test cases shall be
  1244.          executed to explore the response of the IUT. Since in general the
  1245.          X.400 (1984) Series of Recommendations do not define the expected
  1246.          behaviour in these situations, these tests can be "passed" with
  1247.          almost any behaviour apart from catastrophic failure by the IUT.
  1248.          
  1249.          Information in the PIXIT may also provide some constraints on the
  1250.          test cases that can be executed.
  1251.          
  1252.          12.4  Execution of Tests
  1253.          
  1254.          It is recommended that the testing of Message Handling Systems
  1255.          should be done in the order of RTS, then MTS(P1) and then IPMS(P2)
  1256.          testing.
  1257.          
  1258.          However the order of test cases in the test suites does not imply
  1259.          an order of execution. Apart from the general recommendation that
  1260.          for IPMS(P2)/MTS(P1) the Initial Test Group should be executed
  1261.          first, the order of execution of tests can be determined by the
  1262.          test operators taking into account their test environment and test
  1263.          tools.
  1264.          
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.